A programmable controller (hereinafter, “PLC”), a motion controller (hereinafter, “MC”), and an HMI (Human Machine Interface: display and SCADA (Supervisory Control And Data Acquisition)) have conventionally been used to control machines such as processing machines and assembling machines. Recently, a control system using a plurality of PLCs is often constructed for a case where a manufacturing line is formed with a plurality of devices, in addition to a case where a single device is controlled. The control system constructed by using the PLCs has two systems, (1) a link control system in which a plurality of PLCs, each of which includes a CPU (Central Processing Unit) unit and a network unit, is connected to each other via a network, and (2) a multi-CPU control system in which a plurality of CPU units is mounted on a base unit and the respective CPU units are connected to each other via a bus to form a PLC.
(1) Link Control System
The link control system requires data exchange between the PLCs as explained above, and to realize this, the PLCs are connected to each other by an FA (Factory Automation) network to exchange data. In this link control system, data is exchanged between the PLCs via link devices. FIGS. 1-1 is a schematic of one example of the configuration of the link control system and the link devices. FIGS. 1-2 is a schematic of one example of the content of the link device in the PLC of the control system shown in FIGS. 1-1. A control system 500 is configured so that PLCs 501-1 to 501-4, each of which has a CPU unit 502 and a network unit 503, are mutually connected to each other via an FA network 504. Each of the PLCs is called “station” and thus the PLCs 501-1 to 501-4 are respectively called “station 1 to station 4”. The CPU unit 502 includes a link device 510, and data is exchanged between the PLCs 501-1 to 501-4 via each link device. Device values of other stations are periodically copied in the link device 510 of its own device, and the link device 510 has a function corresponding to that handled as a shared memory among the PLCs 501-1 to 501-4 connected to the FA network 504.
As shown in FIG. 1-2, one type of assignment is provided in the link device 510 through the network and the same setting of the assignment is used in each CPU 502 of the stations. However, when the assignment is to be provided in the link device 510, areas in the link device 510 to be written by one of the stations are continuously collected in one location. This is because when device values of other stations are periodically copied into the link device 510 of the own station, a plurality of data is efficiently transferred between the stations by collectively transmitting the plurality of data (device values collectively stored in the one location) in one transmission (see, for example, Patent document 1).
For example, in the link device 510 of each of the stations, device values of the station 1 are written in areas of addresses “B00 to B0F” (hereinafter, “block 1”), device values of the station 2 are written in areas of addresses “B10 to B1F” (hereinafter, “block 2”), device values of the station 3 are written in areas of addresses “B20 to B2F” (hereinafter, “block 3”), and device values of the station 4 are written in areas of addresses “B30 to B3F” (hereinafter, “block 4”). However, the own station can only write data in the areas of the station corresponding to a write station, but can only reference the areas of the other stations. For example, in the link device 510 of the station 1, the block 1 is where the station 1 itself can write device values, while the block 2 is where the station 2 writes device values and thus the station 1 can only reference the device values in the station 2. Furthermore, the blocks 3 and 4 are where the stations 3 and 4 write device values respectively, and thus, the station 1 can only reference the device values therein. The station 1 collectively stores the device values of the own station in the block 1, and thus periodically and collectively transmits these device values to the other stations.
(2) Multi-CPU Control System
The multi-CPU control system is explained below. When a plurality of PLCs is used to control a single device, one CPU is generally provided in each of the PLCs. However, one PLC is often formed with multiple CPUs instead, and a device may be collectively controlled by the one PLC. Similarly, when the manufacturing line is formed with a plurality of devices, one CPU is generally provided in each of the PLCs and a plurality of these PLCs is used to control the line. However, one PLC is formed with multiple CPUs instead, and a plurality of devices may also be collectively controlled by the one PLC (see, for example, Nonpatent literature 1). The control system having the PLC formed with such a multi-CPU configuration as above is called “multi-CPU control system” in this specification.
FIG. 2 is a schematic of the configuration of the multi-CPU control system. A multi-CPU control system 600 includes CPU units 602-1 to 602-4 mounted on a base unit 601. Provided in the base unit 601 is a bus 603 that connects between the CPU units 602-1 to 602-4. In the multi-CPU control system 600, data is mutually exchanged between the CPU units 602-1 to 602-4 via each shared refresh device.
FIG. 3-1 is a schematic of each shared refresh device of the multi-CPU control system, and FIG. 3-2 is a schematic of one example of setting for the shared refresh device in each PLC of the control system of FIG. 3-1. This figure shows that the multi-CPU control system is formed with the two CPU units 602-1 and 602-2. Each of the CPU units 602-1 and 602-2 includes the shared refresh device. Device values of the other CPUs are periodically copied into the shared refresh device of the own CPU. The shared refresh device has a function corresponding to that handled as a shared memory between the CPU units 602-1 and 602-2 connected to each other via the bus 603. It is noted that the function of periodically copying the device values of other CPU units into the device of the own CPU unit is called “multi-CPU auto-refresh function”.
As shown in setting 610 of the shared refresh device of FIG. 3-2, when a refresh source CPU is the CPU unit 602-1, a head address in which a device value of the CPU unit 602-1 is written is set to “D00” as the multi-CPU auto-refresh function, and a head address in which a device value of the CPU unit 602-2 is written is set to “D10” as the same function. When the refresh source CPU is the CPU unit 602-2, a head address in which the device value of the CPU unit 602-1 is written is set to “D10” as the multi-CPU auto-refresh function, and a head address in which the device value of the CPU unit 602-2 is written is set to “D00” as the same function. The number of points of the device value at this time is 16.
As shown in FIG. 3-1, by setting the multi-CPU auto-refresh function in the above manner, addresses “D00 to D0F” of the CPU unit 602-1 are an area written by the CPU unit 602-1 itself, and addresses “D10 to D1F” of the CPU unit 602-1 are an area where device values in addresses “D00 to D0F” of the CPU unit 602-2 are written. Here, the CPU unit 602-1 can only reference the device values written by the CPU unit 602-2. Likewise, the addresses “D00 to D0F” of the CPU unit 602-2 are an area written by the CPU unit 602-2 itself, and the addresses “D10 to D1F” of the CPU unit 602-2 are an area where the device values in the addresses “D00 to D0F” of the CPU unit 602-1 are written. Here, the CPU unit 602-2 can only reference the device values written by the CPU unit 602-1.
As shown in FIG. 3-1 and FIG. 3-2, when the assignment is provided in the shared refresh device, the multi-CPU auto-refresh function is configured to continuously collect the device values written by one CPU in one location. This is because when the device values of other CPU units are periodically copied into the shared refresh device of the own CPU unit, a plurality pieces of data is efficiently transferred between CPU units by collectively transmitting the pieces of data (device values collectively stored in one location) in one communication.
The explanation so far indicates each outline of the link control system and the multi-CPU control system. Generally, a control program for PLC or MC used to control machines such as processing machines and assembling machines and a screen program for HMI have conventionally been described by using addresses of devices. FIG. 4 is a schematic of one example of a conventional control program. This figure shows a control program 701 described in a ladder program and a device table 702 in which device data used for the control program are written. As shown in the control program 701, the ladder program is described by a contact symbol 711 and a coil symbol 712. For example, when the control program for the link control system is to be described, a program for a portion related to data exchange between PLCs is described by using “B0” that indicates a link device. And when the control program for the multi-CPU control system is to be described, a program for a portion related to data exchange between CPUs is described by using “D0” that indicates a shared reference device.
Conventionally, it is general that the system of describing the program by using addresses of devices as shown in FIG. 4 has been used for the control program and the screen program. Recently, however, a system in which the program is described by using label names and each label name is separately associated with an address of each device is being generalized. FIG. 5 is a schematic of one example of a control program using labels. The control program 701, the device table 702, and a label-to-device association table 703 that associates a device with a label are represented in a development tool shown in the left side of FIG. 5. More specifically, the control program 701 is described by using labels, and devices and labels which can be used are previously associated with each other in the label-to-device association table 703. And the labels are respectively converted to corresponding devices upon compiling. After the conversion, the control program 701 is described by using the devices as shown in the right side of FIG. 5.
A label name has a data type such as BOOL and WORD. Therefore, when a label name is to be associated with a device, a BOOL-type label name is simply associated with a BOOL-type device, and thus there is no restriction in the association between a label and an address of a device. Moreover, any name can be given to the label name so that the content of the data can be identified by its name, and thus readability of the control program is improved as compared with the case where the control program is described by using devices. In terms of these points, creation of the control program by using label names can be more efficient as compared with the conventional case where the control program is created by using device addresses.
In the link control system 500 which mutually exchanges data between the PLCs 501 via the link devices, when each program for the PLCs 501 is described by using label names, it is desirable to use a same label name for data to be exchanged between the PLCs 501. The same goes for the multi-CPU control system 600 which exchanges data between the CPU units 602 via the shared refresh devices.
The label names are individually managed by each PLC 501 in the link control system 500. Therefore, if the same label name is to be used for the data exchanged between the PLCs 501, persons in charge for creation of each control program for the PLCs 501 have to previously “agree” to use the same label. The same goes for the multi-CPU control system 600 which exchanges data between the CPU units 602 via the shared refresh devices.
To unfailingly use the same label name in a plurality of PLCs 501, only the agreement between the persons in charge may cause any miss to occur due to failure of communication between the persons or the like. To solve this problem, as a technology for using the same label name between the PLCs 501, for example, a technology of sharing the label name between tools for creating programs for the PLCs 501 is proposed (see, for example, Patent document 2).    Patent document 1: Japanese Patent Application Laid-Open No. H6-311202    Patent document 2: International Publication No. 02/042853, Pamphlet    Patent document 3: Japanese Patent Application Laid-Open No. 2003-15705    Nonpatent literature 1: Q Corresponding MELSECNET/H Network System: Mitsubishi General-Purpose Sequencer MELSEC-Q, [online], Mitsubishi Electric Corp., December 2005.